Agile is one of the most misunderstood and misused concepts in software engineering.
For starters, Agile is not a process to follow, you are not Agile if you have scrums, and 2-week sprints. You are Agile if you tend to release software often and get regular feedback from your users. Nothing more.
It’s a sensible way to approach the fact that requirements are hard to write down accurately at the start of a project. So, you break up the project into bits and then react (that’s the agility bit) based on the feedback (read as lots of small Waterfalls).
From our experience, before Agile was a thing and there was only the Waterfall approach, you didn’t get far delivering software to a trading desk without understanding that the requirements would emerge as you went. It’s just no-one called it Agile.
But it’s a tradeoff. Agile isn’t inherently better (where better means more productive). Actually, knowing all the requirements up front, being able to stick to a plan, not get distracted and not waste time in endless update meetings would be MUCH faster but that’s not the reality we live in.
To be effective, Agile also needs an environment where there’s trust and benefit of the doubt. Sticking to an agreed to plan and having a clear delivery contract in place can be vital when memories have a tendency to become unclear 12 months later and it turns out the stakeholder bet on the wrong horse.
Thanks to Bennet for reminding us of what Agile software development is really about “The real measure of your team’s agility is how often you can release updates and whether it’s easy to get feedback from the user. That’s it.”
Link to the original article here.
If you haven’t read it before – the concept of agile began here.
It’s very simple: - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan